The Policy and Charging Control (hereinafter PCC) functionality is deployed in 3GPP TS 23.203 for Evolved 3GPP Packet Switched domain, including both 3GPP accesses (GERAN/UTRAN/E-UTRAN) and Non-3GPP accesses.
The PCC architecture includes, amongst other entities, a Policy and Charging Control Rules Function (hereinafter PCRF) in charge of policy control decision and flow based charging control functionalities, as well as in charge of provision of PCC rules to be enforced at the bearer layer; a Policy and Charging Enforcement Function (hereinafter PCEF) in charge of service data flow detection based on filters included in the PCC rules received from the PCRF, as well as in charge of PCC rules enforcement at the bearer layer; and an Application Function (hereinafter AF) for offering applications (in which the service is requested at a signalling layer whereas it is delivered at a bearer layer), the control of IP bearer resources according to what has been negotiated. This AF transfers dynamic session information to the PCRF, namely description of the media to be delivered at the bearer layer.
Regarding the communication between the above PCC entities, as disclosed in 3GPP TS 23.203, PCRF and PCEF communicate through a so-called Gx interface, whereas PCRF and AF communicate through a so-called Rx interface. In particular, the PCRF thus provides control rules to the PCEF through this Gx interface, whereas the AF provides the description of the media to be delivered at the bearer layer to the PCRF through this Rx interface.
Regarding the control rules submitted from the PCRF to the PCEF, these control rules include, although are not limited to, those PCC rules disclosed in 3GPP TS 23.203, and can be provided upon establishment or modification of an IP Connectivity Access Network (hereinafter IP-CAN) session.
Moreover, these control rules are determined or generated by the PCRF based on: information obtained from the AF via the Rx reference point, for example, the description of the media commented above, session data, and subscriber related information; information obtained from the PCEF through the Gx interface, for example IP-CAN bearer attributes, request type, subscriber related information and location information; information obtained from a Subscription Profile Repository (hereinafter SPR) through a so-called Sp interface, for example, subscriber and service related data; and other locally configured information at the PCRF.
Regarding the description of the media to be delivered at the bearer layer, which is provided from the AF to the PCRF, the description of the media may include one or more media components. A media component can be regarded as a portion of an AF session conveying information about media, such as media type, format, IP address, port(s), transport protocol, bandwidth, and direction. In this respect, the media described by a media component can be either bi- or unidirectional. On the other hand, media using the so-called Real-time Transport Protocol (hereinafter RTP) for transport may also have associated RTCP. If so, the media component also conveys information about the associated RTP Control Protocol (hereinafter RTCP), such as port and possibly bandwidth. Moreover, each media component may include media subcomponents, wherein each media subcomponent can be regarded as a portion of a media component describing a bi- or unidirectional IP flow.
At present, a huge variety of Internet Services have been developed wherein a user accessing a particular service site is redirected towards a different service site or Web portal. In particular, some user-initiated traffic may be redirected to an information page, where users can be informed about their current usage, or about a tariff change due to roaming, or because the user is out of his time range. Moreover, users might be requested to perform actions such as confirmation or acceptance of new conditions, buy a voucher, etc.
However, current PCC procedures and architectural elements are not prepared to handle this sort of redirection services and there is thus a need to determine in the PCC architecture what services require a redirection, and can be considered to be redirection services, what policies to apply and how to properly charge such redirection services; and, more specifically, in those scenarios where an effective service authorization depends on actions carried out during the redirection.